(I posted this article to comp.unix.aix and comp.security.unix today.) Revision 3.29 of lsof (for LiSt Open Files) is now available. It has some important AIX changes. (Lsof lists files open to Unix processes and runs on a wide range of Unix dialects, including: AIX 3.2.4, 3.2.5, 4.1, and the IBM RISC/System 6000 4.1.1 DC/OSx 1.1 Pyramid ES, Nile and S series EP/IX 2.1.1 the CDC 4680 FreeBSD 1.1.5.1 and 2.0 Intel-based systems HP-UX 8.x and 9.x HP systems (some combinations) IRIX 4.0.5H, 5.2, 5.3, SGI systems and 6.0 Linux 1.0.9, 1.1.47, Intel-based systems 1.1.61, 1.1.64, 1.1.75, and 1.2.5 NetBSD 1.0 and 1.0A Intel and SPARC-based systems NEXTSTEP 2.1 and 3.[0123] all NEXTSTEP architectures Novell UnixWare 1.1, Intel-based systems 1.1.1, and 1.1.2 OSF/1 1.3, 2.0, 3.0, and the DEC Alpha 3.2 RISCOs 4.52 MIPS R2000-based systems SCO Open Desktop or Open Intel-based systems Server 1.1, 3.0, and 5.0 Sequent Dynix 3.0.12 the Sequent Symmetry Sequent PTX 2.1.[156] and Sequent systems 4.0.2 Solaris 2.[1234] Sun 4 and i86pc systems SunOS 4.1.[1234] Sun 3 and 4 Ultrix 2.2, 4.2, 4.3, DEC RISC and VAX and 4.4 V/88 R32V3, R40V4.2, and Motorola M88K systems R40V4.3 The good news about revision 3.29 is that it supports AIX 4.1.1, and that its Configure script now uses /usr/bin/oslevel to detect the AIX version automatically. (If your AIX version doesn't have oslevel -- i.e., it predates 3.2.5, lsof will warn you that it is assuming an AIX version of 3.2.5.) The bad news is that in response to IBM APAR ix49183, lsof no longer uses readx() by default to obtain loader structures, meaning that by default it no longer reports on open executable and shared library files. As distributed, lsof 3.29 provides the -X option to enable the use of readx(). Lsof may be compiled with either default or with readx() permanently disabled or enabled. APAR ix49183 describes an AIX 3.2.x and 4.1[.x] kernel bug that is triggered by use of readx(). Typically the bug happens in a busy system when the readx() application obtains a virtual memory segment ID (SID) and is delayed in using it by other processes. If the readx() application uses the SID at precisely the right (wrong) time, some pages of an in-memory copy of a file system directory are erroneously set to zero. When another application process, distinct from the one using readx(), calls the kernel -- e.g., with open(2) -- asking that the affected directory be searched, the kernel's dir_search() encounters the zeroed pages and hangs the application process. Once dir_search() hangs, the application process can neither be killed nor stopped. The 00FAQ file of the lsof 3.29 distribution discusses APAR ix49183 in more detail. I haven't seen this bug happen and no one has reported a sighting to me, but I believe the bug could happen and have reluctantly produced an lsof that can be tuned to adjust to its possibility. My thanks go to Kevin Ruderman <rudi@acs.bu.edu> for reporting the AIX kernel bug and the possibility that lsof might trigger it. Lsof revision 3.29 is available, as always, from its "home" site, vic.cc.purdue.edu, in pub/tools/unix/lsof. Vic Abell, lsof author